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Claims 1-8 are pending in the Application. 
Claims 1-8 stand rejected 

I. REJECTION UNDER 35 U.S.C.. $ 102 

Claims 1-8 have been rejected under 35 U.S. C. § 102 as being anticipated by 
Srinivasan, et al., U.S. Patent Application No. 2001/0051948A1 ("Srinivasan"). The 
Applicants respectfully traverse the rejection of claims 1-8 under 35 U.S.C. § 102. 

Claim 1 is directed to a method for storing data that has at least some entries with 
multiple value attributes. The method includes the steps of profiling the data to determine 
whether the data should be stored in an attribute table, or, alternatively, in a merged table 
and an overflow table, and storing the data optimally based on the profiling step. The 
Examiner contends that Srinivasan discloses the method for storing data that has at least 
some entries with multiple attribute values including profiling the data to determine 
whether the data should be stored in an attribute table on the grounds that the attribute 
table of FIGURE 4 allegedly shows that the types, that is "EID", "ATTRNAME", 
"ATTRVAL" and "ATTRKTND 1 ' are sorted categories. (Paper No. 6, page 3.) The 
Examiner further asserts that this inherently indicates that the data must have been profiled 
before the table could be created. (Paper No. 6, page 3; Paper No. 9, page 5.) (In the 
instant action, Paper No. 9, the Examiner omits the assertion with respect to the attribute 
types but, nevertheless, repeats the conclusion that the table of FIGURE 4 inherently 
shows that the data must have been profiles. Paper No. 9, page 5.) The Applicants 
respectfully disagree with the foregoing allegations for several reasons. 

The table of FIGURE 4 is an attribute store table for entries in an exemplary 
directory information tree (DIT). (Srinivasan, page 3, U 38.) Entries in the directory 
information tree are represented by one or more rows in the table. (Id.) The Examiner 
does not specifically state what "sorted categories" refers to. Srinivasan refers to 



2 



AT9-98-884 



PATENT 



additional system categories for object attributes that are stored in entries in the 
"ATTRKIND" column of the attribute store table (such as access and modification 
privileges). (Srinivasan, page 3, K 40.) However, there is nothing therein that refers to 
sorting. The only reference to sorting the Applicants find in Srinivasan is with respect to 
catalog tables. (Srinivasan, page 5, f 56.) Srinivasan teaches that catalog tables may be 
maintained in a sorted list of entries. Id. 

The Examiner relies on FIGURE 5 of Srinivasan as disclosing a merged table and 
an overflow table. However, FIGURE 5 is an attribute store table similar to FIGURE 4, 
but including additional entries (that is, rows) that describe metadata associated with a 
particular entry (100) of the exemplary DIT. (Srinivasan, page 4, 1(44.) Nothing in 
Srinivasan has been shown to teach that the attribute store table of FIGURE 4 is merged 
table and the attribute store table of FIGURE 5 is an overflow table, or vice versa. Also, 
nothing identified in Srinivasan discloses that data is alternatively stored in an attribute 
table of FIGURE 4 or an attribute table of FIGURE 5, and, nothing identified in 
Srinivasan discloses that the data is profiled to determine whether it should be stored in an 
attribute table without subschema entries to define metadata (FIGURE 4) or including 
subschema entries to define metadata (FIGURE 5). (Metadata refers to information that 
describes the data in the system, such as information describing the structure and 
parameters of the tables and data maintained in the system. Srinivasan^ page 3, ^ 42.) 
The teaching referred to in Paper No. 6 discusses the content of the ATTRVAL for 
subschema entries (indicated by the value "2" in the EID column). (Srinivasan, page 4, 
45, 46.) The teaching, relied upon further discloses that the ATTRVAL column of a 
subschema entry can also identify the quantity of values to be provided for the defined 
attribute type. (Srinivasan, page 4, 1[47.) 

The Examiner responds that the plurality of attribute names in the table of 
FIGURE 4 clearly shows the step of profiling, that is, categorizing the data to determine 
whether the data is stored in certain tables. (Paper No. 9, page 2) (referring to the 
Applicants' Second Reply. Under 37 C.F.R. § 1.111, hereinafter "Applicants' Second 
Reply," page 3, U 1).. . This allegation fails for several reasons.. As an initial matter, there 
is no evidence that Srinivasan "categorizes" data to determine whether to store it in 
certain tables. The table of FIGURE 4 simply includes a column for storing a system 
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category for object attributes, such as kinds relating to access and modification privileges. 
(Srinivasan, page 3, H 40.) Furthermore, the claim does not recite categorizing data to 
determine whether data is stored in certain tables. At least, "certain tables" are not an 
attribute table, a merged table and an overflow table. It is not a reasonable construction of 
limitations in a claim to omit terms from the claim language. See MPEP. § 2143.03 
(stating that all words in a claim must be considered when judging the patentability of the 
claim). Furthermore, claim 1 recites profiling the data to determine whether to store the 
data in an attribute table or, alternatively , in merged table and overflow table. Again, the 
allegation does not consider the claimed invention as recited. 

The Examiner also responds that the features shown in FIGURES 4 and 5 of 
Srinivasan are defined in the Specification, namely that merged tables include single value 
attributes and overflow tables are sets of multiple value attributes. (Paper No. 9, page 3) 
(referring to the Applicants' argument with respect to FIGURE 5 in Applicants' Second 
Reply). However, simply because the tables of FIGURE 4 include both single valued and 
multiple valued attributes does not make either or both of them a merged table and a 
overflow table. As the Applicants previously showed, there is nothing in Moreover, as 
the Applicants previously showed, there is nothing in Srinivasan that teaches that 
FIGURE 4 is a merged table or FIGURE 5 is an overflow table as recited in claim 1 or 
vice versa. Also, nothing identified in Srinivasan discloses that data is alternatively stored 
in an attribute table of FIGURE 4 or an attribute table of FIGURE 5, and, nothing 
identified in Srinivasan discloses that the data is profiled to determine whether it should be 
stored in an attribute table without subschema entries to define metadata (FIGURE 4) or 
including subschema entries to define metadata (FIGURE 5). Additionally, the discussion 
in the Specification that an attribute may be stored both in a merged table and an overflow 
table does not make the tables of FIGURE 4 or 5 either a merged table or an overflow 
table as recited in claim 1 simply because both of them include both single-valued 
attributes and multiple-valued attributes. The foregoing notwithstanding, the attribute 
store tables of FIGURES 4 and 5 include a "AttrName" column identifying the object 
attribute being described. (Srinivasan, page 3, K 39.) . The Examiner identifies this as a 
single- valued attribute in the tables of FIGURES 4 and 5. (Paper No. 9, page 3.) 
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However, there is no teaching in Srinivasan that discloses that the name of an attribute is 
an attribute. 

The assertion that the teaching in Srinivasan inherently shows that the data must 
have been profiled before the table could be created also fails. The claim does not recite 
profiling data to create a table. Anticipation requires that a single reference teach the 
identical invention as claimed MPEP. §2131. The alleged inherent characteristic in 
Srinivasan on its face does not disclose the limitation of claim 1 with respect to profiling 
the data to determine whether the data should be stored in attribute table or, alternatively, 
in a merged table and an overflow table. Moreover, the Examiner does not provide any 
rationale explaining how the attribute table of FIGURE 4 inherently shows that the data 
must have been profiled to determine whether the data should be stored in attribute table 
or, alternatively, in a merged table and an overflow table. The Examiner must provide a 
basis in fact and/or technical reasoning to reasonably support the determination that the 
allegedly inherent characteristic necessarily flows from the teaching of the reference. 
MPEP. §21 12. 

With respect to the Applicants' showings with respect to inherency, the Examiner 
responds that the Examiner did not realize it was necessary "to provide the clear 
correlation in which one of ordinary skill in the art one should realize the table of FIGURE 
4 could have been created without the step of profiling the data or categorizing the data 
prior to creating the table for the storing step." (Paper No. 9, page 2) (referring to the 
Applicants' Second Reply, page 3, K 2.) . It is indisputable that it is the Examiner's burden 
to establish that an allegedly inherent characteristic is necessarily present in the thing 
taught, and would be so recognized by persons of ordinary skill in the art. MPEP § 2112. 
That notwithstanding, the Examiner's own contention that a person of ordinary skill in the 
art should realize that the table of FIGURE 4 could be created without the step of 
profiling the data or categorizing the data prior to creating the table for the storing step 
refutes any contention that the profiling step is inherent. This plainly shows that the 
allegedly inherent characteristic in not necessarily present in thing taught. 

The Examiner further explains that if the data were profiled, there would be no 
need to identify the different attributes of the data for storing, much less creating the table 
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to store them under different attribute names. (Paper No. 9, page 2.) Again, this refutes 
the Examiner's own reliance on inherency. (The Applicants do not necessarily agree or 
disagree with the consequence of the data profiling advanced by the Examiner. The claim 
recites a profiling step, and anticipation requires that the reference teach this step whether 
the Examiner agrees with its pertinence, or otherwise.) 

The Examiner further contends that the merged and overflow tables are known 
tables prior to profiling the data and concludes that here was no need to explain the 
inherency with respect to the unclaimed feature of the data be profiled before the table be 
created. (Paper No. 9, pages 2-3.) Again these assertions are unavailing. Whether the 
merged and overflow tables are known before the data is profiled is not germane to the 
analysis because it is not an element of the claimed invention. The reference to the 
profiling of data before the table being created in the Applicants' Second Reply referred to 
the Examiner's assertions made with respect to the limitations of claim 1, not the claim 
itself (Applicants' Second Reply, page 3.) Indeed the, Applicants plainly stated that the 
Examiner's allegations did not address the limitations of claim 1. (Applicants' Second 
Reply, page 3, and hereinabove). 

In other words, the Examiner the Office Action mailed on May 22, 2003, Paper 
No. 6, rejected claim 1 on the ground that the teaching in Srinivasan "inherently indicated 
that the data must have been profiled before the table [of FIGURE 4] could be created " 
(Paper No. 6, page 3) (emphasis added). The Applicants, in responding, traversed, in part 
on the basis that this ground of rejection was not related to a determination whether the 
data should be stored in a merged table or an overflow table. (Applicants' Second Reply, 
page 3.) The Examiner now responds that the Applicants arguments specifically 
addressing the Examiner's explicit language were arguing unclaimed limitations. (Paper 
No. 9, pages 2-3.) Thus, the Examiner's response is tantamount to an admission that the 
ground of rejection of claim 1 in Paper No. 6 does not read on the limitations of claim 1. 
Consequently, the rejection of claim 1 under 35. U.S.C. § 102 is improper on its face. 

Additionally, the teachings of Srinivasan do not discuss storing data optimally 
based on a profiling step. With respect to the optimal storing, the Examiner also refers to 
the teaching in Srinivasan that discusses storing data in a normalized format that is 
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optimized for querying and searching. (Paper No. 6, page 3) (citing Srinivasan, page 1, 
Tf 77). By the plain terms thereof, this disclosure refers to searching and querying 
optimization, not optimal storage of data. 

With respect to the step of storing optimally based in the profiling step, the 
Examiner responds that optimally searching and querying directly impact the step of 
optimally storing of data. (Paper No. 9, page 3.) The Examiner provides no rationale 
how a optimally searching and querying impact optimally storing. (Paper No. 9, page 3.) 
Rather, the Examiner states that optimally storing of data must be understood by the ways 
of how to store the data to make the step of storing optimally. (Paper No. 9, page 3.) 
The Applicants understand this assertion to be a tautology, with which the Applicants do 
not disagree. However, it does not explain how a storing optimally is searching or 
querying optimally. Storing is not querying or searching and that is not changed by the 
adverb "optimally." Thus the Examiner's assertion that optimal searching and querying are 
part of the steps involved in the step of optimal storage of data is unsupported by evidence 
or the plain meaning of the terms querying and storing. Moreover, even if, for the sake of 
argument, optimal searching and querying were part of the steps involved in the step of 
optimal storage of data, they do not teach a step of storing (optimally or otherwise). 
"Being part of is not the standard for anticipation; all of the limitations must be disclosed 
by the reference. MPEP §2131. The conclusion that the storing step of claim 1 is not 
beyond the scope of Srinivasan is conclusory and without any evidentiary support. 

Anticipation requires that a single prior art reference teach the identical invention 
as recited in the claim. MPEP § 2131. In other words, all of the limitations of the claim, 
arranged as required by the claim must be taught by the reference. Id. Because 
Srinivasan has not been shown to teach the identical invention of claim 1, the Applicants 
respectfully contend that claim 1 is allowable under 35 U.S.C. § 102 over Srinivasan. 

Claim 2 depends from claim 1 and recites the method thereof in which the entries 
with single value attributes are stored in the merged table. The Examiner relies on the 
tables in FIGURES 2C and 5 which the Applicants understand to be alleged to teach the 
merged table as recited in claim 2. (See Paper 6, page 3; Paper No. 9, page 5.) Assuming, 
for the sake of argument, that either or both of the tables in FIGURES 2C and 5 of 
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Srinivasan teach a merged table, there is nothing identified with respect thereto that 
discloses that the entries are single value attributes. Indeed, on the contrary, paragraph 47 
of Srinivasan teaches that the attributes may have multiple values, and the Examiner has 
relied on pages 4-6, of Srinivasan as disclosing multiple value attributes. (See Paper 
No. 6, page 3; Paper No 9, page 5) (rejecting claim 1 over Srinivasan on the ground that 
Srinivasan discloses a method for storing data that has at least some entries with multiple 
value attributes). In particular, Srinivasan teaches that a subschema entry could identify 
whether an attribute type comprises either single value, or multiple values of that attribute. 
(Note that whether the attribute is single-valued or multi-valued is defined by the schema, 
not whether a particular attribute is assigned multiple values or only a single value. 
(Srinivasan, page 4, 1|47.) For example, the country, ('c') attribute defined by the 
LDAPv3 user schema to be single valued. See RFC 2256 p. 3 (1997).) Thus, the 
Applicants respectfully contend that Srinivasan has not been shown to teach the identical 
invention of claim 2, and therefore, claim 2 is allowable under 35 U.S. C § 102 over 
Srinivasan. 

The Examiner responds that claim 2 "defines single- valued attribute data to be 
stored in [a] merged table." (Paper No. 9, page 4.) The Applicants respectfully submit 
that this mischaracterizes claims in a patent. Claims are not definitions but detenriine the 
metes and bounds of the right to exclude. [CITE to nvidia] Likewise, the contention that 
claims 2 and 3 are distinct subcombinations and usable together with claim 1 further 
mischaracterizes patent claims. Claims 1, 2 and 3 are distinct inventions. It is not relevant 
whether claims 2 and 3 are usable with claim 1. Claims 2 and 3 separately include the 
limitations of claim 1 from which they each separately depend. The foregoing 
notwithstanding, claim 2 is a method including a storing step in which single-valued 
attributes are stored in a merged table. Simply identifying an attribute in the table of 
FIGURE 4 or FIGURE 5 of Srinivasan as single-valued or multi-valued does not make 
either of these a merged table or an overflow table as recited in the claim. Furthermore, a 
method claim is drawn to a process, that is it is "dynamic" and to anticipate the reference 
must teach the operations as recited in the claim. Looking at a static table of FIGURE 4 
or FIGURE 5 and first inferring that they teach the merged table of claim 2 because they 
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allegedly include a single-valued attribute and then inferring that the reference then 
inherently teaches storing single- valued attributes in a merged table is illogical. 

Claim 3 depends from claim 1 and is directed to the method thereof in which 
entries with multiple-value attributes are stored in the overflow table. The Examiner 
refers to the telephone number and manager catalog tables of FIGURES 6C and 6D, 
respectively. (Paper No. 6, page 4.) These catalog tables are maintained as indexes into 
the attribute store tables. (Srinivasan, page 5, U 54.) F° r eacn attribute type that is 
indexed, a separate catalog table is maintained. (Id.) Each catalog table contains two 
columns, the first contains the EID of an entry or object having an attribute of the catalog 
attribute type, and the second provides the attribute value for the corresponding EID. 
(Id.) The Applicants note that each of the tables illustrated includes a single attribute 
value. The Examiner notes that Srinivasan states that a subschema entry could identify 
whether an attribute type comprises either a single value or multiple value attributes, 
however, nothing is disclosed in Srinivasan that the catalog tables illustrated are multiple- 
value attributes. Consequently, there is no justification for concluding that the catalog 
tables as taught by Srinivasan disclose overflow tables as recited in claim 3. (These tables 
are exemplary and a catalog table as taught by Srinivasan for the country attribute would 
be directed to a single value attribute in accordance with the LDAP schema.) 
Additionally, assuming, for the sake of argument, that the tables in FIGURES 5, 6C and 
6D disclose overflow tables as recited in claim 3, then, at least with respect to the table in 
FIGURE 5, it cannot be a merged table as asserted with respect to claim 2. In other 
words, the table cannot be both a merged table and an overflow table. Thus, the 
Applicants respectfully assert that Srinivasan has not been shown to teach the identical 
invention of claim 3, and therefore claim 3 is allowable under 35U.S.C. § 102 over 
Srinivasan. 

Similarly to claim 2, the Examiner responds that claim 3 "defines multiple-valued 
attribute data to be stored in [an] overflow table." (Paper No. 9, page 4.) The Applicants 
respectfully submit that this mischaracterizes claims in a patent. Claims are not definitions 
explaining the invention but determine the metes and bounds of the right to exclude. See 
S3 Inc. v. nVIDIA Corp., 259 F.3d 1364, 1369, 59 U.S.P.Q.2d 1745, 1748 (Fed. Cir. 
2001). Likewise, the contention that claims 2 and 3 are distinct subcombinations and 
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usable together with claim 1 further mischaracterizes patent claims. Claims 1, 2 and 3 are 
distinct inventions. It is not relevant whether claims 2 and 3 are usable with claim 1. 
Claims 2 and 3 separately include the limitations of claim 1 from which they each 
separately depend. The foregoing notwithstanding, claim 2 is a method including a storing 
step in which single- valued attributes are stored in a merged table. Simply identifying an 
attribute in the table of FIGURE 4 or FIGURE 5 of Srinivasan as single- valued or multi- 
valued does not make either of these a merged table or an overflow table as recited in the 
claim. Furthermore, a method claim is drawn to a process, that is it is "dynamic" and to 
anticipate the reference must teach the operations as recited in the claim. Looking at a 
static table of FIGURE 4 or FIGURE 5 and first inferring that they teach the merged 
table of claim 3 because they allegedly include a single-valued attribute and then inferring 
that the reference then inherently teaches storing single- valued attributes in a merged table 
is illogical. 

Claim 4 is directed to the method of claim 1 in which the overflow table is an 
attribute table. The Examiner again refers to FIGURES 5, 6C and 6D as showing per 
attribute tables. As an initial matter, the Applicants respectfully disagree that FIGURE 5 
of Srinivasan shows a per attribute table. Referring to FIGURE 5, FIGURE 5 shows 
table entries corresponding to at least eight attributes. With respect to the catalog tables 
of FIGURES 6C and 6D, which are exemplary, Srinivasan makes no distinction between 
single-valued attributes and multi- valued attributes with respect to the entries in the 
catalog tables. Indeed, as the Examiner has noted, attributes may be either single- valued 
attributes or multi- valued attributes. However, there is nothing in the discussion of the 
catalog tables that indicates that the attributes corresponding to their respective tables are 
particularly one or the other, that is single-valued or multi-valued. Additionally, 
Srinivasan teaches that an attribute type can be modified by editing the appropriate 
subschema entry in the attribute table including, modifying a single- valued attribute type to 
be a multi- valued attribute type. (Srinivasan, page 8, 1(93.) Therefore, the Applicants 
respectfully contend that Srinivasan does not show an overflow table, as recited in 
claim 1 , from which claim 4 depends which is an attribute table. Additionally, claim 4 
incorporates the limitations of claim 1 , and as previously discussed, Srinivasan has not 
been shown to teach the identical invention of claim 1 , and therefore necessarily does not 
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teach the identical invention of claim 4. For at least these reasons, the Applicants 
respectfully assert that claim 4 is not anticipated by Srinivasan and is thus allowable under 
35 U.S.C.. § 102 over Srinivasan. 

Claim 5 is directed to the method of claim 1 in which a majority of the data is 
stored in a merged table and a set of additional values for the multiple- value attributes are 
stored in the overflow table. The Examiner asserts that FIGURES 2C and 5 exemplify a 
merge table in which a majority of single values are stored. (Paper No. 6, page 4.) The 
Applicants respectfully disagree. There is nothing that distinguishes the attributes in 
FIGURES 2C and 5 as either single- valued attributes or multi- valued attributes. In this 
respect, as the Applicants previously noted, in accordance with the LDAP schema, 
whether an attribute is single- valued or multi- valued is a "property" of the attribute. That 
is, whether a particular attribute admits, or may be assigned, multiple values or only single 
values, respectively is set by the schema. A single-valued attribute is not an attribute that 
in a particular embodiment has only a single value associated therewith and a multi- value 
attribute is not an attribute that in a particular embodiment has more than one value 
assigned to it. Thus, although the tables in FIGURES 2C and 5 illustrate only single 
values assigned to each of the exemplary attributes therein, it cannot be concluded that 
these are single-valued attributes. Srinivasan does not, for the purposes of the table 
entries in the tables of FIGURES 2C and 5, distinguish between single-valued attributes 
and multi- valued attributes. The Examiner further asserts that the tables in FIGURES 6C 
and 6D are tables with multiple attributes for an instant entry of table 5. (Paper No. 6, 
page 4.) Again, the Applicants respectfully disagree. Referring to FIGURES 6C and 6D 
of Srinivasan, these figures incontrovertibly show a single attribute value for each entry. 
(Srinivasan, FIGURES 6C and 6D.) Note that each entry corresponds to a node in the 
DIT, which node is identified by the value in the EID entry in the respective tables. Thus, 
the Applicants also respectfully disagree with the Examiner's assertion that these tables 
illustrate more than one manager and/or telephone per person. Again, although the 
attribute types corresponding to each of the catalog tables may be either single-valued 
attributes or multi- valued attributes, Srinivasan does not distinguish between these for the 
purposes of the catalog tables of which FIGURES 6C and 6D are exemplary, nor has the 
Examiner identified teaching in Srinivasan to the contrary. 
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The Examiner responds that the table of FIGURE 5 includes both single-valued 
attributes and multi- valued attributes. (Paper No. 9, page 4) (referring to the Applicants' 
Second Reply, page 6, ^| 2). . It is not necessary to determine whether the attributes 
illustrated in the table of FIGURE 5 include both types of attributes. While the table of 
FIGURE 5 may, for the sake of argument include both single- valued attributes and multi- 
valued attributes, the Examiner has not shown that Srinivasan teaches that a majority of 
the data is stored in a merged table and a set of additional values for the multiple-value 
attributes are stored in the overflow table. 

For at least the foregoing reasons, the Applicants respectfully contend that 
Srinivasan does not teach the identical invention of claim 5. Consequently, claim 5 is 
allowable under 35 U.S.C.. § 102 over Srinivasan. 

Claim 6 is directed to the method of claim 1 in which the profiling step parses the 
data to identify entries with single- value attributes. The Examiner relies on the teaching in 
Srinivasan with respect to the ATTRVAL column of a subschema entry which can be 
used to identify the quantity of values to be provided for the denned attribute type, for 
example, a parameter that specifies a minimum or maximum number of telephone number 
values allowed for that attribute. (Paper No. 6, page 4) (citing Srinivasan, page 4, ^ 47). 
This teaching does not refer to a step of parsing data. As Srinivasan teaches, subschema 
entries are rows that define metadata inserted in the attribute store table. {Srinivasan, 
pages 3-4, U 43.) Metadata is information that describes data in the system and particular, 
that describes the structure and parameters of database and data maintained in the system. 
{Srinivasan, page 3, 1[42.) The Examiner also relies on the inherency discussed 
hereinabove in conjunction with claim 1. (Paper No. 6, page 4.) The Applicants have 
addressed the reliance on inherency hereinabove. For the reasons discussed in conjunction 
with claim 1 , and the foregoing reasons with respect to the teachings in Srinivasan, 
paragraph 47, the Applicants respectfully contend that Srinivasan has not been shown to 
teach the identical invention of claim 6. Consequently, claim 6 is allowable under 
35 U.S.C. § 102 over Srinivasan. 

Claim 7 is directed to the method of claim 1 in which the profiling step parses the 
data to identify given operations that are performed on the data once stored. Because, for 
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shown to teach the profiling step as recited in claim 1, Srinivasan necessarily fails to teach 
the invention of claim 7. Therefore, claim 7 is allowable under 35 U.S. C. § 102 over 
Srinivasan. 

Claim 8 depends from claim 1 and is directed to the method thereof in which the 
data is stored in a relational database backing store. Again, claim 8 incorporates all the 
limitations of claim 1 from which it depends, and which as discussed hereinabove is 
allowable under 35 U.S. C. § 102 over Srinivasan. Consequently, claim 8 is also allowable 
under 35 U.S.C. § 102 over Srinivasan. 



III. RESPONSE TO ARGUMENTS 

The Examiner has considered the Applicants arguments in the Applicants' Second 
Reply but these have been deemed unpursuasive. (Paper No. 9, page 2.) The Examiner 
has responded to the Applicants' arguments with respect to claims 1, 2, 3 and 5. (See 
Paper No. 9, pages 2-4.) The Applicants have addressed the Examiner's response in 
conjunction with response to the rejection of these claims hereinabove. The Applicants 
respectfully note that the Examiner has not responded to the Applicants' showings with 
respect to claims 4, 6, 7 and 8 in the Applicants' Second Reply. The Examiner is 
respectfully reminded that where, as here the Examiner repeats a ground of rejection in 
response to the Applicants' traverse, the Examiner should address the substance of the 
Applicants' remarks. MPEP § 707.07(f). 

IV. CONCLUSION 

As a result of the foregoing, it is asserted by Applicants that the remaining claims 
in the Application are in condition for allowance, and respectfully request an early 
allowance of such claims. 
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Applicants respectfully request that the Examiner call Applicants* attorney at the 
below listed number if the Examiner believes that such a discussion would be helpful in 
resolving any remaining problems. 

Respectfully submitted, 

WINSTEAD SECHREST & MINICK P C. 



Attorneys for Appellant 




P.O. Box 50784 
400 North Ervay Street 
Dallas, Texas 75201 
(512) 370-2808 
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